1. Validator software will automatically signal all of its supported features when started, without further prompt from the operator.

   2. Validator operators will now have to manually arm for feature gates via a validator CLI command.

The summary mentions that the process is automated and manual human action is removed, which would imply 1. But further below it mentions that the operator runbook now includes the new transaction step, which would imply 2.

@ripatel-fd :
In this SIMD, we describe mechanism #1, but that is actually a client-specific design. Other clients or forks of clients could remove that automatic behavior and have validators signal feature support another way or on another cadence.

However, the more fundamental principle of this proposal is that actual activation of the feature is automatic based on percentage of stake support, default 95%. While the Labs client no longer represents anywhere near 95% of stake, it's true that no one entity or client implementation (including Firedancer) would be able to block activation en masse until they represent 5+% of stake.

Even if this SIMD is approved and implemented, feature-gate key-holders can continue to negotiate with all the clients to determine when to queue the feature for activation, as we do now -- and we envision separate SIMDs around formal governance on approving/queuing proposed features. So this SIMD wouldn't prevent the level of human control that currently exists.
But if we should use something other than stake-weight to determine how many validators are compatible with a particular feature, this is the place to discuss it.

We (@ripatel-fd and I) spent some more time discussing this proposal and we had several more comments on it:

• The proposed changes implicitly hard fork on client software updates. There is a significant issue with the implicit activation of features on hard forks. This delegates the power to change consensus rules entirely to Solana Labs, which contradicts the expectation that the blockchain is governed by validators, stakers, holders, etc. Although it is a conscious choice for validators to upgrade their software, regular updates to software are a forcing function causing the activation of features. Similarly, a security fix shipped with a new features will certainly cause majority of stake to take the new update, even if they do not want the new feature activation.
• This poses a particularly hard problem for adoption of Firedancer: If we start to deploy to mainnet beta, we will most definitely start out with less than 5% of stake. This would that in order to even have a chance of being stable on mainnet we would need more than 5% of stake. Its a major bootstrapping problem.
• We need to see a specification for the structure of the new feature accounts.

We propose that there is 3 phase system for feature gate ratification:

• Creation: anyone can create a new feature gate account, which is owned by the feature program. Creating a new feature gate must not have any additional runtime overhead.
• Version availability: Each leader at the end of each slot, increments a counter in the feature accounts for all features they support, but are not activated. They also update a field in the feature account with the slot they are currently on. If this "last_updated_slot" is from the previous epoch during this process, store the previous counter and last updated field in the account in "previous epoch fields" and set the counter to 0. The feature becomes "available" or "armed for activation" when: 1) that previous epoch counter is very nearly 100% of slots_per_epoch and, 2) the previous epoch last_updated_slot field is in the immediately previous epoch. A feature is disarmed when the conditions are not met.
• Activation: This should be an explicit, manual, on chain governance vote based on validator stake weight with some quorum. The properties of this vote (its duration, quorum, delay to activation after passage, participants) are to be determined but a majority vote for the new feature must result in the automated activation of the feature at an epoch boundary. This gives all stakeholders time to vie for, or protest the new feature. The feature must remain armed until the completion of the vote, if it becomes disarmed and then later rearmed, the vote should probably restart. An on-chain program should be devised for this process prior to the feature gate change.
• After activation, a feature becomes active forever and leaders can stop updating the feature account. Clients can remove the gates in the code.

We would be happy to collaborate on proposal(s)/specification(s) which go in the above direction. As it stands, it introduces the aforementioned bootstrapping issue, which would give no recourse for the community to dissent to new features. This could prolong the development of clients with less resources.

More importantly than our own concerns though (which are admittedly self-interested) this proposal would further Solana Labs' hegemony on the chain via their control of client features. This may be against the wants of validators who actually control the blockspace of Solana. It should not be the version of the Solana Labs client or the clients implicit capabilities which control the blockspace, it must be the people.

We propose that there is 3 phase system for feature gate ratification:

@lheeger-jump , thanks for your thoughts. To clarify, the system we envision is 2 phases:

• Feature queuing: currently done manually by a single person, but to transition to an explicit governance vote. This creates the feature account (but this could be split into two steps -- account creation by "anyone" and some update of account state by the governance signer to indicate queuing -- if this division is needed).
• Version availability: the proposal in this SIMD

To me, these two steps are synonymous to the Version Availability and Activation steps you describe, with the same essential stake and participation requirements, just in the opposite order. Can you please expand on how changing the order of these steps changes the amount of control any particular client wields?

Thanks for clarifying @CriesofCarrots. I should have read the SIMD more carefully. I think we are ideologically aligned in that this is only a "feature support discovery" mechanism, and that the actual activation logic can be specified in a separate PR. This is definitely a step in the right direction. The above criticism regarding risk to another clients that me and @lheeger-jump posted is therefore invalid.

We had some thoughts about how the permissioned part can be removed (adding new features to the queue).
These changes would also allow keeping the logic entirely as eBPF, such that zero protocol-level complexity is introduced.

It would involve changing the negotiation API like so:

• Feature support advertisement transactions are only posted by leaders in every rotation
• Support is accumulated in a variable-size window that is a multiple in an epoch
• During each window, each feature account tracks the number of leader rotations during which support for this feature has been advertised
• Instead of writing a bitmap, explicitly call a feature program instruction and write to the corresponding feature account
• Feature gate support can be calculated by either advertised_rotation_cnt*4/slots_per_epoch (share of total stake) or advertised_rotation_cnt*4/blocks_produced_in_epoch (share of active stake)
• A feature can be added to the queue by the feature account authority

Example API

enum FeatureInstruction {
    /// Initializes a feature account
    /// # Account references
    ///   0. `[writable]` The feature account
    ///   1. `[signer]` The feature authority
    Initialize,

    /// Closes a feature account without nominating it
    /// # Account references
    ///   0. `[writable]` The feature account
    ///   1. `[signer]` The feature authority
    ClosesFeature,

    /// Advertise support for feature. Can only be called by current leader, once per rotation.
    /// # Account references
    ///   0. `[writable]` The feature account
    ///   1. `[signer]` Current leader
    LeaderAdvertise,

    /// Nominates a feature for a governance vote.
    /// # Account references
    ///   0. `[writable]` The feature account
    ///   1. `[signer]` The feature authority
    Nominate,
}

The disadvantage of this change is that it increases the amount of transactions and data required to activate a feature.
(Also relevant comment by @CriesofCarrots: #72 (comment))

@lheeger-jump , thanks for your thoughts. To clarify, the system we envision is 2 phases:

• Feature queuing: currently done manually by a single person, but to transition to an explicit governance vote. This creates the feature account (but this could be split into two steps -- account creation by "anyone" and some update of account state by the governance signer to indicate queuing -- if this division is needed).
• Version availability: the proposal in this SIMD

To me, these two steps are synonymous to the Version Availability and Activation steps you describe, with the same essential stake and participation requirements, just in the opposite order. Can you please expand on how changing the order of these steps changes the amount of control any particular client wields?

This should be more clear in the SIMD and should be very explicit. Thanks for the clarification. Nonetheless, the arming mechanism described is relevant to the discussion.

To me, these two steps are synonymous to the Version Availability and Activation steps you describe, with the same essential stake and participation requirements, just in the opposite order. Can you please expand on how changing the order of these steps changes the amount of control any particular client wields?

The 3 steps I described are to allow anyone to create a new feature, but not to allow them to be able to be the activator (that would be governance). I think what I am saying is that anyone can do creation (i.e. anyone can propose new features) and that is separate from activation which should not be voted on. I think you basically say that here:

(but this could be split into two steps -- account creation by "anyone" and some update of account state by the governance signer to indicate queuing -- if this division is needed).

Can you please expand on how changing the order of these steps changes the amount of control any particular client wields?

By splitting up the first step into creation and then activation after version availability is satisfied, you disallow the feature owner from ramming the feature on and the choice to enable is explicit. Less about client control. The client control is more about a lack of governance on feature activation.

Hey everyone! It's time to dust this one off again now that we have #88 and #89 merged!

We've introduced a completely revised version of this proposal, re-written from scratch. It should assess all of the discussion points raised above in previous threads, as well as numerous concerns raised in various offline discussions.

I'd love it if we can open back up the review process for this one, and start working toward a new feature activation process!

@CriesofCarrots @lheeger-jump @ripatel-fd

P.S. I've included a link to the Feature Gate program's reference implementation in the PR description.

@ripatel-fd and I can take another look in the next few days